This Page Is Inserted by IFW Operations 
and is not a part of the Official Record 



BEST AVAILABLE IMAGES 

Defective images within this document are accurate representations of 
the original documents submitted by the applicant. 

Defects in the images may include (but are not limited to): 
. BLACK BORDERS 

♦ TEXT CUT OFF AT TOP, BOTTOM OR SIDES 
. FADED TEXT 

• ILLEGIBLE TEXT 

♦ SKEWED/SLANTED IMAGES 

• COLORED PHOTOS 

• BLACK OR VERY BLACK AND WHITE DARK PHOTOS 

♦ GRAY SCALE DOCUMENTS 

IMAGES ARE BEST AVAILABLE COPY. 



As rescanning documents will not correct images, 
please do not report the images to the 
Image Problem Mailbox. 



(19) 



J 



Europaisches Patentamt 
European Patent Office 
Office europccn des brevets 



(12) 



(11) EP 1 079 658 A2 

EUROPEAN PATENT APPLICATION 



(43) 


Date of publication: 


(51) int ci 7; H04Q 11/04 




28.02.2001 Bulletin 2001/09 


(21) 


Application number: 00306971.3 




(22) 


Date of filing: 15.08.2000 




(84) 


Designated Contracting States: 


(72) Inventors: 




AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 


• Xiaolin, Lu 




MC NL PT SE 


Piano, Texas 75024 (US) 




Designated Extension States: 


♦ Ylm, Susan 




AL LT LV MK RO SI 


Piano, Texas 75074 (US) 


(30) 


Priority: 20.08.1999 US 378139 


(74) Representative: Potter, Julian Mark 






D. Young & Co., 


(71) 


Applicant: Texas Instruments Incorporated 


21 New Fetter Lane 




Dallas, Texas 75251 (US) 


London EC4A1DA (GB) 



(54) Element management system for a digital subscriber line access multiplexer 



(57) An access multiplexer (10) for a digital sub- 
scriber line (DSL) communications network, having el- 
ement management system (EMS) capability, is dis- 
closed. A host computer (17) is coupled to the DSL ac- 
cess multiplexer (DSLAM) (10) over a serial interface 
(27, 28). A controller (25) of the DSLAM includes an 
EMS agent for receiving command control and informa- 
tion request messages from the host computer (17) over 
the serial interface (27, 28). The EMS agent issues sig- 
nals to a software process, such as Ihe DSL channel 
manager in response to such messages, and generates 
replies to the host computer (17) over the serial interface 



(27, 28) upon execution of the requested operation. The 
controller (25) also operates in response to command 
control and information request messages initiated at 
user computers (U) that reside on a network (14). A Sim- 
ple Network Management Protocol (SNMP) agent exe- 
cuted by the controller (25) receives SNMP messages 
over the network (14), and initiates the execution of a 
method routine to obtain the requested information or 
effect the corresponding control. As a result, both a local 
host computer (17) and also users on a network (14) 
may monitor, manage, and control the operation of the 
DSLAM (10). 
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Description 

[0001] A copy of USSN 09/360,747, entitled "Efficient 
Packet Buffer Management in a Digital Subscriber Line 
Access Multiplexer", filed 26 July 1999 is furnished s 
herewith on the filing date of this application to be placed 
in the European Patent Office dossier for this application 
and made available for public inspection on and from 
the date of publication of this application and is incorpo- 
rated herein by reference. 

[0002] This invention relates to the field of data com- 
munications, and is more particularly directed, although 
not exclusively, to the architecture, operation, and con- 
trol of access multiplexers for effecting such communi- 
cations. 

[0003] In recent years, the data rates at which com- 
munications are carried out over conventional tele- 
phone networks and wiring have greatly increased. 
These increases are due, in large part, to newly adopted 
techniques of multiplexing and modulating signals rep- 
resentative of the messages or data being communicat- 
ed, resulting in greatly improved communication band- 
width. In addition, the carrier frequencies at which such 
communications are being carried out have also in- 
creased in recent years, further improving the bit rate. 
[0004] These higher data rates are achieved in one 
relatively new type of current modem communications 
technology, referred to in the art as digital subscriber line 
("DSL") . DSL refers generically to a public network 
technology that delivers relatively high bandwidth over 
conventional telephone company copper wiring, gener- 
ally at limited distances. DSL has been further separat- 
ed into several different categories of technologies ac- 
cording to specific expected data transfer rates, the 
types and lengths of the medium over which data are 
communicated, and schemes for encoding and decod- 
ing the communicated data. According to this technolo- 
gy, data rates between DSL modems may be far greater 
than current voice modem rates. Indeed, current DSL 
systems operate (or are projected to operate) at data 
rates ranging from on the order of 500 Kbps to 18 Mbps 
or higher. According to certain conventional techniques, 
such as the protocol referred to as Asymmetric Digital 
Subscriber Line (ADSL) and which corresponds to ANSI 
standard T1.413, the data communication rates are 
asymmetrical. Typically, the higher rate is provided for 
so-called downstream communications, that is from the 
telephone network central office to the customer mo- 
dem, with upstream communication from the customer 
modem to the central office having a data rate consid- 
erably lower than the downstream rate. 
[0005] An integral part of a DSL communications net- 
work is referred to in the art as the Digital Subscriber 
Line Access Multiplexer, or "DSLAM". DSLAMs are typ- 
ically located at a central office of the telephone network, 
and include multiple DSL modem ports into which client 
modems may connect. The primary function of a 
DSLAM is to multiplex client data communications from 



its multiple DSL modem ports into a network, such as a 
local area network (LAN) which may include a server 
and an Internet gateway; return data communications 
from the network are also demultiplexed by the DSLAM 
for communication to the clients via the DSL ports. 
[0006] Conventional DSLAMs are typically realized 
by way of multiple line cards, each of which supports 
one or more DSL ports. The communications received 
at the DSL ports are typically in packet form, each hav- 
ing headers or tails (or both) containing the appropriate 
routing information for the packet message. A DSLAM 
controller function performs the appropriate framing and 
data formatting by way of which the packets received at 
the DSL ports are conveyed, according to the appropri- 
ate protocols, to a network interface card (NIC) in the 
DSLAM and thus to the network. In general, convention- 
al DSLAMs modulate and demodulate multiple DSL 
channels corresponding to multiple client locations, ef- 
fect line concentration in the communications network, 
provide an interface to the communications network, 
and provide management of the communications sys- 
tem. 

[0007] These important functions provided by 
DSLAMs in a communications network, particularly in a 
DSL environment, are relatively complex in nature, es- 
pecially considering the high data rate communications 
that are supported. The design and realization of a 
DSLAM has therefore been relatively complex, particu- 
larly in terms of system analysis and debugging. 
[0008] Furthermore, considering the line concentra- 
tion function performed thereat, a typical DSLAM has 
access to the operating characteristics of many DSL 
channels, as well as bidirectional access to client mo- 
dems. Heretofore, this access has not been fully utilized 
in the management and operation of the communica- 
tions network. 

[0009] An embodiment of the present invention pro- 
vide a DSLAM having sufficient processing capability to 
effect element management system (EMS) functionality 
relative to multiple communications channels. 
[0010] A further embodiment of the present invention 
provides such a DSLAM in which such a management 
system may be effected both locally, by a host computer 
coupled to the DSLAM, and also remotely by way of a 
network. 

[0011] A further embodiment of the present invention 
provides such a DSLAM in which debugging of the 
DSLAM and its operation is facilitated by way of inter- 
face of a local host computer to the DSLAM. 
[0012] A further embodiment of the present invention 
provides such a DSLAM that can update the operating 
software of client modems, under the control of a host 
computer or a network-linked computer. 
[0013] Other embodiments and advantages of the 
present invention will be apparent to those of ordinary 
skill in the art having reference to the following specifi- 
cation together with its drawings. 
[0014] Embodiments of the present invention may be 
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implemented by way of a digital subscriber line access 
multiplexer (DSLAM), preferably implemented by way 
of digital signal processors (DSPs), and having an ele- 
ment management system agent operable thereupon. 
The element management system agent interfaces with 
a host computer, for example by way of a high speed 
serial interface, by way of which debugging, system 
management, user control, and other operations may 
be carried out upon the DSLAM. 
[0015] According to another aspect of the present in- 
vention, the DSLAM includes a network interface agent, 
by way of which other computers, for example comput- 
ers on a local area network with the DSLAM, may ac- 
cess and operate the element management system of 
the DSLAM, such that system management, user con- 
trol, and other system functions may be initiated remote- 
ly for execution at the DSLAM. 
[0016] Embodiments in accordance with the present 
invention will now be described, by way of example only, 
and with reference to the accompanying drawings, in 
which: 

[0017] Figure 1 is an electrical diagram, in block form, 
of a digital subscriber line (DSL) communications net- 
work into which the preferred embodiments of the 
present invention may be implemented. 
[001 8] Figure 2 is an electrical diagram, in block form, 
of a digital subscriber line access multiplexer (DSLAM) 
constructed according to the preferred embodiments of 
the present invention. 

[001 9] Figure 3 is an electrical diagram, in block form, 
of the architecture of a digital signal processor (DSP) 
according to which the DSLAM controller of the pre- 
ferred embodiments of the present invention may be im- 
plemented. 

[0020] Figure 4 is a block diagram illustrating the soft- 
ware architecture under which the DSLAM of Figure 2 
operates, according to the preferred embodiments of 
the present invention. 

[0021] Figure 5 is a block diagram illustrating the soft- 
ware architecture of the element management system 
(EMS) according to the preferred embodiment of the in- 
vention. 

[0022] Figure 6 is a block diagram illustrating the soft- 
ware architecture of the EMS service application imple- 
mented in a host computer according to the preferred 
embodiment of the invention. 

[0023] Figure 7 is a block diagram illustrating the soft- 
ware architecture of the SNMP-EMS service application 
implemented in a remote, network-connected, user 
computer according to the preferred embodiment of the 
invention. 

[0024] Referring first to Figure 1, a digital subscriber 
line (DSL) communications network into which the pre- 
ferred embodiment of the present invention may be im- 
plemented will first be described. The preferred embod- 
iment of the invention will be described in connection 
with a DSL network, as it is contemplated that the 
present teaching is particularly beneficial when applied 



to DSL communications; of course, it is to be understood 
that the present teaching may also have applicability to 
other types of communications, as will be readily appar- 
ent to those skilled in the art having reference to this 

5 specification. Further, the particular DSL network of Fig- 
ure 1 is described herein by way of example only, it being 
contemplated that those skilled in the art having refer- 
ence to this specification will be readily able to realize 
the benefits of the present teaching in DSL networks ac- 

io cording to other arrangements and, as noted above, al- 
so in data communication according to other technolo- 
gies. 

[0025] The DSL communications network of Figure 1 
includes multiple client locations H, each of which may 
correspond to a home or an office client location. In this 
DSL arrangement, illustrative client location H 0 includes 
a DSL modem 2 0 which handles communications to and 
from client computer 4 0 . Telephone handset 6 0 is con- 
nected in parallel with DSL modem 2 0 to splitter 8 0 

20 which, as is conventional in the art, provides the appro- 
priate filtering operation to forward voice communica- 
tions to handset 6 0 and data communications to DSL 
modem 2 0 . Splitter 8 0 is connected to one of local tele- 
phone network facilities TWP, each of which may be re- 

2S alized by way of conventional twisted-pair copper wires. 
Others of client locations H may be similarly construct- 
ed, or realized in such other fashion as is known in the 
art. 

[0026] The example of Figure 1 corresponds to the 
30 type of DSL communications in which analog voice sig- 
nals travel at a lower frequency than data communica- 
tions, permitting the simultaneous overlay of the two 
classes of traffic on the same telephone network facili- 
ties. Alternatively, as is known in the art, so-called "split - 
35 terless" DSL may be used, in which voice communica- 
tions are received and converted by the DSL modem 
into packet communications, and communicated over 
the telephone network as digital packets in similar fash- 
ion as the communicated data. The present teaching 
40 may be applied with equivalent benefit to DSL commu- 
nications according to such splitterless technologies, as 
well. 

[0027] In the example of Figure 1 , twisted-pair facili- 
ties TWP are connected to central office CO either di- 

45 rectly, or as a combination of twisted-pair and fiber optic 
physical facilities, with repeaters and other network el- 
ements (not shown) provided as necessary for reliable 
communication. Where voice communications are in- 
volved, as in this example, central office CO will typically 

so be located at a telephone provider site. Alternatively, 
DSL communications may be limited to data communi- 
cations, in which case central office CO may be a server 
location, such as a public or proprietary (Internet or in- 
tranet) server location with which client locations H may 

55 communicate data, in which case the analog voice sig- 
nal capability would likely not be present. 
[0028] As shown in Figure 1 , each of twisted-pair fa- 
cilities TWP is received by digital subscriber line access 
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multiplexer (DSLAM) 10, the construction of which will 
be described in further detail hereinbelow relative to the 
preferred embodiments of the invention. In this exam- 
ple, DSLAM 1 0 is able to separate the voice signals from 
the data communications received over facilities TWR 
and forward these signals to the public switched tele- 
phone network (PSTN) via voice digital switch 1 2, which 
also resides at central office CO; of course, voice com- 
munications from PSTN to a client location H, such as 
to handset 6 0 at client location H 0 , may also be handed 
by digital switch 12 and DSLAM 10, in the conventional 
manner. 

[0029] For data communications, DSLAM 10 is in 
communication with a local network, such as local area 
network (LAN) 14 at central office CO as shown in Fig- 
ure 1 . LAN 1 4 may be arranged in the conventional fash- 
ion for LANs, as is well known in the art, such as an 
Ethernet network, over which communications may be 
carried out in the conventional manner. Such LANs are 
compatible with packet communication, as is well 
known. In the example of Figure 1, local servers 15 re- 
side on LAN 1 4, such that client locations H may access 
locally stored data therefrom via the DSL connection. 
Additionally, particularly in the telephone network appli- 
cation, Internet gateway 1 9 resides on LAN 1 4, such that 
client locations H may bidirectionally access the Internet 
via central office CO. 

[0030] According to the preferred embodiment of the 
present invention, user computers U resident on LAN 
14 are able to access DSLAM 10 in order to effect sys- 
tem management and monitoring functions, as will be 
described in further detail hereinbelow. The physical lo- 
cation of user computers U will depend upon the char- 
acteristics of LAN 14. User computers U directly con- 
nected to LAN 14 will typically be located within or near 
central office CO. Additionally, it is contemplated that 
other networks (such as other LANs) may be coupled to 
LAN 1 4, for example by way of a router or other remote 
access arrangement, permitting user computers U that 
are physically distant from central office CO to access 
LAN 14 and thus access DSLAM 10 by way of dial-up 
or other access techniques. Such remote access is 
shown in Figure 1 by remote user computer U R . 
[0031] According to the preferred embodiment of the 
invention, DSLAM 10 is also connected to host compu- 
ter 17. Host computer 17 is preferably a personal com- 
puter or workstation that is physically located near 
DSLAM 10, and that is used to access and control sys- 
tem management functions within DSLAM 10 as will be 
described in detail hereinbelow. In larger installations, it 
is contemplated that host computer 17 will typically be 
coupled to multiple similarly-constructed DSLAMs 10, 
rather than to a single DSLAM 10 as suggested by Fig- 
ure 1. 

[0032] Referring now to Figure 2, an illustrative hard- 
ware architecture of DSLAM 10 according to the pre- 
ferred embodiments of the invention will now be de- 
scribed. As shown in Figure 2, DSLAM 10 includes mul- 



tiple analog front end (AFE) functions 20, each of which 
serve as a DSL port and thus bidirectionally connect to 
one of twisted pair facilities TWP, to receive communi- 
cations from a connecting client location H. AFE func- 

5 tions 20 are constructed as circuit cards, including 
mixed-signal (i.e., involving both digital and analog op- 
erations) integrated circuits, to provide all loop interface 
and line driver functions necessary for full-duplex DSL 
communications. Examples of integrated circuits that 

10 may be used to realize AFE functions 20 include the 
TLV420AD1 2 central office ADSL codec, and THS6002 
line driver, both available from Texas Instruments Incor- 
porated. 

[0033] DSL channel transceivers 22 of DSLAM 10 are 

is each bidirectionally connected to multiple ones of AFE 
functions 20. In the example of Figure 2, each DSL 
channel transceiver 22 connects to four AFE functions 
20; of course, the specific number of AFE functions 20, 
and thus DSL channels, to be processed through a giv- 

20 en one of DSL channel transceivers 22 will vary with the 
particular DSLAM architecture and also the processing 
capacity of the DSL channel transceivers 22. DSL chan- 
nel transceivers 22 are each preferably a programmable 
digital device for executing the necessary signal 

2S processing operations for both transmission and receipt 
of the data pay load. These operations include such 
functions as echo cancellation, encoding and decoding 
of the data into appropriate subchannels for transmis- 
sion, and Fast Fourier Transform (FFT) signal process- 

30 jng between the frequency and time domains. Particu- 
larly at DSL data rates, the digital data processing ca- 
pacity and power of DSL channel transceivers 22 is pref- 
erably of a high level, preferably with capability on the 
order of that provided as digital signal processors of at 

35 least the capability of TMS420CL548 DSPs available 
from Texas Instruments Incorporated. Each of DSL 
channel transceivers 22 are connected to framer func- 
tion 24, which is also preferably implemented as a DSP 
such as the TMS420CL548 noted above. Framer func- 

40 tion 24 performs the appropriate formatting of the digital 
data into the appropriate packets and frames for 
processing within DSLAM 10. While two DSL channel 
transceivers 22 are explicitly illustrated in Figure 2, it is 
of course contemplated that any number of DSL channel 

45 transceivers 22 may feed (and be fed by) framer function 
24, depending upon the particular architecture and ca- 
pability of DSLAM 10. 

[0034] DSLAM controller 25 is bidirectionally connect- 
ed to framer function 24 on one side; on its network side, 

50 DSLAM controller 25 is bidirectionally connected to 
Ethernet network interface card (NIC) 26, RS422 high- 
speed serial interface 27, and RS242 serial interface 28. 
As shown in Figure 1, Ethernet NIC 26 interfaces 
DSLAM 10 to LAN 14, and serial interfaces 27, 28 inter- 

ss face DSLAM 10 to host computer 17. In the communi- 
cation of data to and from the DSL channels, DSLAM 
controller 25 performs the function of handling data flow 
control and channel management of the DSL channels 
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connected to AFE functions 20 in DSLAM 10, as well as 
data flow control between the DSL channels and NIC 
26, specifically in performing Layer 2 and Layer 3 net- 
work protocol processing according to various protocols 
such as P PR IP routing, ARP, and the like. An example 
of a preferred approach to performing such network pro- 
tocol processing is described in copending application 
S.N. 09/360,747, entitled "Efficient Packet Buffer Man- 
agement in a Digital Subscriber Line Access Multiplex- 
er", filed July 26, 1 999, commonly assigned herewith 
and incorporated hereinto by this reference. 
[0035] According to the preferred embodiment of the 
present invention, another function carried out by 
DSLAM controller 25 is the control of the setup and op- 
eration of DSLAM 10, in response to control instructions 
from host computer 17 received via serial interfaces 27, 
28, or from user computers U by way of Simple Network 
Management Protocol (SNMP) messages communicat- 
ed over LAN 14 to Ethernet NIC 26. In the example of 
Figure 2, control or information requests may be gener- 
ated by user computer U as SNMP messages commu- 
nicated over network 14' and, via router 29, over LAN 
14 of DSLAM 10. Of course, user computers U that re- 
side on LAN 1 4 will issue control and monitoring instruc- 
tions by way of SNMP messages directly over LAN 14 
to DSLAM 1 0. These control and management functions 
of DSLAM 10 according to the preferred embodiment of 
the invention, as initiated by host computer 17 or user 
computers U, will be described in further detail herein- 
below. 

[0036] DSLAM controller 25 may be implemented as 
a single DSP device for performing the DSLAM control- 
ler functions described above, having capabilities such 
as the TMS420LC548 DSP available from Texas Instru- 
ments Incorporated, as noted above. Alternatively, in 
the event that higher processing capability DSPs, such 
as those of the TMS420C6X class of DSPs available 
from Texas Instruments Incorporated, are used for other 
functions in DSLAM 10 (i.e., framerl unction 24 and DSL 
channel transceivers 22), and if sufficient processing ca- 
pacity remains available in that DSP to handle the func- 
tions of DSLAM controller 25, the digital functions of 
DSLAM 10 may then be realized in a single DSP device. 
Still further in the alternative, DSLAM controller 25 may, 
of course, be realized by way of dedicated custom logic 
circuitry. As such, the functional boundaries of DSLAM 
10 shown in Figure 2 may or may not represent the 
boundaries of integrated circuits used to realize these 
functions, depending upon the processing capacity of 
the particular circuits. 

[0037] However, it is preferable that DSLAM controller 
25 be realized as a DSP, preferably one compatible with 
such other DSPs as are used within DSLAM 10 as DSL 
channel transceivers 22 and framing function 24. This 
DSP realization of DSLAM controller 25 allows for data 
flow through DSLAM 10 without requiring data transla- 
tion and other interface considerations that may other- 
wise be necessary if DSLAM controller 25 were realized 



as a general purpose microprocessor. Additionally, the 
DSP realization of DSLAM controller 25 also permits 
use of the same development platform for the operation 
of DSLAM controller 25 as for the other DSPs within 

5 DSLAM 1 0. Of course, as will become apparent to those 
skilled in the art having reference to this specification, 
many of the benefits of the present teaching may also 
be realized even if DSLAM controller 25 is implemented 
by way of such a microprocessor or other hardware oth- 

70 er than a DSP device. 

[0038] Referring now to Figure 3, an illustrative archi- 
tecture of DSP 1 30, according to which DSLAM control- 
ler 25 may be realized, will now be described in detail. 
The example of DSP 1 30 corresponds to the architec- 
ts ture of the above-noted TMS420LC548, it being under- 
stood that DSPs constructed according to other archi- 
tectures may alternatively be utilized. 
[0039] DSP 130 in this example is implemented by 
way of a modified Harvard architecture, and as such uti- 

20 lizes three separate data buses C, D, E that are in com- 
munication with multiple execution units including expo- 
nent unit 142, multiply/add unit 144, arithmetic logic unit 
(ALU) 136, barrel shifter 148. Accumulators 140 permit 
operation of multiply/add unit 144 in parallel with ALU 

25 136, allowing simultaneous execution of multiply-accu- 
mulate (MAC) and arithmetic operations. The instruction 
set executable by DSP 130, in this example, includes 
single-instruction repeat and block repeat operations, 
block memory move instructions, two and three operand 

30 reads, conditional store operations, and parallel load 
and store operations, as well as dedicated digital signal 
processing instructions. DSP 130 also includes com- 
pare, select, and store unit (CSSU) 1 42, coupled to data 
bus E, tor accelerating Viterbi computation, as useful in 

35 many conventional communication algorithms. 

[0040] DSP 130 in this example includes significant 
on-chip memory resources, to which access is control- 
led by memory/peripheral interface unit 145, via data 
buses C, D, E, and program bus P. These on-chip mem- 

40 ory resources include random access memory (RAM) 
144, read-only memory (ROM) 146 used for storage of 
program instructions, and address registers 148. Pro- 
gram controller and address generator circuitry 149 is 
also in communication with memory/peripheral interface 

45 145, and receives program instruction code from ROM 
146 or from other storage via memory/peripheral inter- 
face 145, and generates control signals applied to each 
of the functional units of DSP 1 30 to control the execu- 
tion of instructions corresponding to the received pro- 

50 gram instruction code. Interface unit 1 58 is also provid- 
ed in connection with memory/peripheral interface 145 
to control external communications. Power, clock and 
control function 150 refers, in general, to control circuitry 
within DSP 130 to handle such functions as power dis- 

S5 tribution and voltage regulation, clock generation, and 
overall control of DSP 130; additionally, power, clock 
and control function 150 may further realize other inter- 
face functions, such as serial and host ports, as well as 
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additional control functions such as timers, JTAG test 
interlace circuitry, built-in self test circuitry, and the like. 
[0041] Figure 4 illustrates the software architecture of 
DSLAM controller 25, as may be implemented by way 
of DSP 130 according to the preferred embodiment of 
the invention. The architecture of Figure 4 is based upon 
real-time kernel 30, which includes functional compo- 
nents upon which the remainder of DSLAM controller 25 
software is based. These components include a real- 
time scheduler, a standard I/O management system, 
and a packet-oriented memory management system ac- 
cording to the preferred embodiments of the present in- 
vention. 

[0042] The real-time scheduler portion of real-time 
kernel 30, according to the preferred embodiment of the 
invention, uses priority-based event driven round robin 
scheduling to handle the asynchronous network inter- 
face data traffic and message transmissions passing 
through DSLAM 10 under the control of DSLAM control- 
ler 25. In this example, each event is described by an 
event descriptor data structure which indicate the type 
and priority of the event, along with event-specific notify 
values, flags, states, and information regarding the de- 
vice and port with which the event is associated. 
[0043] Relative to the standard I/O management sys- 
tem, hardware abstraction layer 31 includes the hard- 
ware dependent portions of driver software for each of 
the interface functions to which DSLAM controller 25 is 
responsive. The device drivers for the DSL channels 
supported by AFE functions 20 (Figure 2), Ethernet in- 
terface via NIC 26, and serial port interfaces 27, 28, are 
preferably developed according to a standard I/O mod- 
el. Application program interface (API) layer 32 resides 
"above" hardware abstraction layer 31, and includes an 
element management system (EMS) port I/O driver 32a, 
DSL channel I/O driver 32b, Ethernet I/O driver 32c, and 
HSSP (high-speed serial port) I/O driver 32d, as illus- 
trated in Figure 4. These drivers in API 32 interfaces to 
the protocol layer of the architecture, represented by 
signal protocol stack 36s and data protocol stack 36d in 
the architecture of Figure 4. 

[0044] Signal protocol stack 36s in the architecture of 
Figure 4 is a protocol stack that is used primarily during 
initialization of communications between a DSL modem 
2 at a client location H (Figure 1) and DSLAM 10. Once 
a bidirectional channel has been established, data pro- 
tocol stack 36d is used for the storage and processing 
of data packets and their associated overhead (i.e., 
headers and tails), as will be described below. 
[0045] Above the protocol stack layer (36s, 36d), var- 
ious system manager software applications reside in 
API layer 38 of the architecture of Figure 4 Network 
manager 38a, host port manager 38b, and DSL channel 
manager 38c each provide a uniform API for top level 
applications in DSLAM controller 25, such top level ap- 
plications including an element management system 
(EMS) agent, DSL channel IP routing, DSL channel PPP 
processing, ARP and SNMP protocols, and the like. 



More specifically, a data structure is provided by DSLAM 
controller 25 that describes the quality of service param- 
eters of each DSL port handled by DSLAM 10, such 
quality of service parameters including bit error rate, sig- 

5 nal-to-noise ratio, delay, data flow and data error con- 
trols, line coding, and the like. DSL channel manager 
38c serves to initialize and drop DSL channels in its 
opening and closing of a port, and also to set up and 
modify the quality of service parameters in the associ- 

JO ated data structure, along with setting and modifying the 
data rates for upstream and downstream traffic. Net- 
work manager 38a and host port manager 38b handle 
communications through their respective ports, in the 
conventional manner and also as described herein. 

1 s Manager applications 38a, 38b, 38c all share a common 
code base for standard I/O management functions, as 
noted above, while providing device-specific manage- 
ment functions. 

[0046] In operation, data packets received and re- 

20 transmitted through DSLAM controller 25 effectively 
make their way through the software architecture of Fig- 
ure 4. For example, a DSL message received by one of 
AFE functions 20 (Figure 2) is received as a group of 
packets by hardware abstraction layer 31, and is then 

25 handled by DSL channel I/O driver 32b, which places 
the packets into data protocol stack 36d. The packets 
in data protocol stack 36d are processed by packet buff- 
er manager 40 according to the various protocols, and 
then handed off to the API layer for processing by the 

30 associated manager application according to the partic- 
ular destination of the message. Once the appropriate 
manager application 38a, 38b, 38c performs its 
processing, the packet is then forwarded back through 
data protocol stack 36d to the appropriate I/O driver 32 

35 for the packet destination. 

[0047] As illustrated in Figure 4, the software archi- 
tecture of DSLAM controller 25 preferably includes 
packet buffer manager 40. Packet buffer manager 40 
corresponds to a group of program instructions that, 

40 when executed by DSP 1 30 as DSLAM controller 25 de- 
scribed above, executes a packet-based memory man- 
agement system for a multi-protocol, multi-channel DSL 
communications system such as DSLAM 10. The 
above-incorporated copending application ' S.N. 

4S 09/360,747 describes the operation of a preferred real- 
ization of packet buffer manager 40, according to which 
DSLAM controller 25 processes each block of data 
through a series of different network interfaces, proto- 
cols, and associated processing, while maintaining the 

so contents of the data block in place in memory, effecting 
a zero-copy packet buffer manager system. In any case, 
the program instructions of packet buffer manager 40 
are preferably stored in ROM 146 of DSP 130 used to 
implement DSLAM controller 25, executed by way of ac- 

55 cess to on-chip RAM 1 44 which stores the data packets 
and any associated overhead. 

[0048] Referring back to Figures 1 and 2, and as not- 
ed above, DSLAM controller 25 carries out various man- 
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agement and monitoring functions relative to the overall 
setup and operation of DSLAM 1 0. According to the pre- 
ferred embodiment of the invention, these functions are 
executed by DSLAM controller 25 in response to control 
instructions from host computer 17 received via serial 
interfaces 27, 28, or from user computers U communi- 
cated over LAN 14 via Ethernet NIC 26. 
[0049] In this regard, DSLAM controller 25 either 
maintains, or can gather on request, certain manage- 
ment and monitoring information regarding the opera- 
tion of DSLAM 10. This information includes the logging 
of events, errors, and alarms that are generated by 
DSLAM 10 itself, management information regarding 
the protocols, coding methods, channel types, and the 
like that are supported by DSLAM 10, overall system 
performance statistics, DSL channel behavior statistics, 
and the performance of central office and client mo- 
dems. As will be described in further detail hereinbelow, 
these data will be utilized in the element management 
system (EMS) of the preferred embodiment of the 
present invention. 

[0050] According to the preferred embodiment of the 
invention, an element management system (EMS) is re- 
alized in connection with DSLAM 10, through the com- 
bination of DSLAM controller 25 with a service applica- 
tion operating on host computer 17 or user computers 
U. This EMS provides the operators and users of 
DSLAM 10 with the ability to select DSL channel rates, 
channel types, and communications protocols to be 
used in the DSL communications, to debug channel op- 
erations, and to turn DSLAM 10 on and off. Additionally, 
it is contemplated that the EMS according to the present 
teaching will provide the ability to download modem soft- 
ware to modems 2 at client locations H, such that up- 
dated modem communications software may be in- 
stalled thereat. 

[0051] Referring now to Figure 5, the overall software 
architecture of the EMS according to the preferred em- 
bodiment of the present invention will now be described. 
It is contemplated that those of ordinary skill in the art 
having reference to this specification will be readily able 
to implement the functionality described hereinbelow 
upon DSLAM 1 0, host computer 1 7, and user computers 
U, regardless of their specific hardware realizations. As 
such, it is contemplated that the functional software ar- 
chitecture provided hereinbelow will provide clear and 
full description of the operation of the EMS system ac- 
cording to the preferred embodiment of the invention. 
[0052] Host computer 1 7 includes EMS service appli- 
cation 40e, and each of user computers U includes 
SNMP-EMS service application 40n. EMS service ap- 
plication 40e of host computer 17 includes a user inter- 
face module 42 and a serial port communication module 
44e for communicating with DSLAM 10 over its serial 
interfaces 27, 28, while SNMP-EMS service application 
40n of user computer U includes user interface module 
42 in combination with SNMP manager 44n, for commu- 
nicating with DSLAM 10 over LAN 14 (directly or indi- 



rectly). 

[0053] Within DSLAM 10, EMS agent 60 communi- 
cates with EMS service application 40e in host computer 
17, and SNMP agent 62 communicates with SNMP- 
5 EMS service application 40n in user computers U. EMS 
agent 60 is a software agent that is executed by pro- 
grammable circuitry within DSLAM 10, such as DSLAM 
controller 25, to handle EMS commands and requests 
from, and to send messages to, EMS service application 
io 40e. EMS agent 60 communicates with host computer 
17 by way of host port manager 38e, which in turn op- 
erates through serial port driver 52e to communicate 
with host computer 17 over one of serial interfaces 27, 
28. SNMP agent 62 is a software agent that similarly 
is responds to commands and requests of an EMS nature, 
via protocol stack 36d, network manager 38a, and net- 
work device driver 52n. Communications with user com- 
puters U are effected by network device driver 52n via 
Ethernet NIC 26 of DSLAM 10, over LAN 14 and (if 
present), router 29 and network 14'. The operation of 
EMS agent 60 and SNMP agent 62 will be described in 
further detail hereinbelow. 

[0054] User interface module 42 in service applica- 
tions 40e, 40n is, in each case, a software module that 
interacts with the human users of DSLAM 10 by way of 
a graphical user interface, and as such corresponds to 
a high-level application upon host computer 17 or user 
computers U, as the case may be. For example, in the 
case where host computer 1 7 and user computers U op- 
erate using the WINDOWS operating system, user in- 
terface module 42 will be implemented as a WINDOWS 
application; the respective serial communications mod- 
ule 44e and SNMP manager 44n are preferably imple- 
mented as dynamic link libraries (DLLs) in this arrange- 
ment. 

[0055] User interface module 42 is preferably realized 
by way of an object-oriented technique in which classes 
are provided for conventional graphical user interface. 
Referring now to Figure 6, the functional blocks of user 
interface module 42 according to the preferred embod- 
iment of the invention will now be described. While the 
example of user interface module 42 is shown in Figure 
6 in connection with serial communications module 44e 
of EMS service application 40e, it is contemplated that 
the functional arrangement of user interface module 42 
within SNMP-EMS service application 40n will be simi- 
larly implemented, having effectively the same win- 
dows, sub-windows, and functionality. 
[0056] As shown in Figure 6, user interface module 
42 includes main window 48 and multiple sub-windows 
50. Each sub-window 50 interacts with DSLAM 10 in re- 
sponse to requests from main window 48 generated 
from user inputs; in this regard, main window 48 prefer- 
ably includes such graphical user interface features as 
toolbars, pull-down menus, dialogs, and the like. Sub- 
windows 50 are each preferably implemented as dialog 
boxes (e.g., by way of the Cdialog class of Microsoft de- 
fined classes in the Microsoft Foundational Class ob- 
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ject-oriented technique). Depending upon the particular 
function of the sub-window 50, the dialog box may be 
modal (requiring its closing prior to accessing other sub- 
windows 50) or modeless (allowing its existence while 
other sub-windows 50 are subsequently opened). 
[0057] Logging sub-window 50a is a modeless win- 
dow that displays logging information generated by 
channel manager 38c or network manager 38a of 
DSLAM 1 0, depending upon the channel that is selected 
by the user via main window 48 or sub-window 50a. The 
logged information may be presented as a list for the 
selected channel, and may include an identification of 
the source ol the channel, the type of messages being 
transmitted or received, and the information itself, which 
may be general channel information, error codes, or 
warning messages, depending upon the current state of 
the selected channel. 

[0058] Alarm and event sub -window 50b is a mode- 
less window that alerts the user of certain events and 
alarms encountered in the operation of DSLAM 1 0. Pref- 
erably, the user can register, with EMS agent 60 or 
SNMP agent 62 of DSLAM 10, the types of alarms and 
events for which alarm and event sub-window 50b will 
receive and display notifications. Examples of these 
events include channel initialization, state change, and 
termination events, channel connection events, and 
channel administration events (i.e., rate changes, er- 
rors, self -test), and the like. Preferably, the events are 
displayed by sub-window 50b in connection with the 
channel identifier, date and time of the event, and iden- 
tification and description of the event. 
[0059] Channel capacity sub-window 50c, according 
to the preferred embodiment of the invention, graphical- 
ly displays the available channel bandwidth for discrete 
multi-tone (DMT) modulation. Sub-window 50c is a 
modeless window, and provides the user with the ability 
to select the particular channel and a range of tones or 
bands to be viewed. 

[0060] Status sub-window 50d is a modeless window 
that displays both overall performance statistics of 
DSLAM 10, as well as the characteristics of individual 
channels selected by the user via main window 48; ad- 
ditionally, such channel status information may be auto- 
matically displayed upon the opening of a new DSL 
channel. The displayed information may include the 
type of channel, channel connection status, upstream 
and downstream bit rates, signaling and framing proto- 
cols, channel statistics such as the number of frames or 
bytes transmitted, received, in error, or dropped, and 
other quality of service (QoS) parameters. 
[0061] Script command window 50e is a general pur- 
pose modeless window by way of which the user may 
directly enter text commands, as an alternative input 
means from main window 48 or the other sub-windows 
50. In contrast, control command sub-window 50f is a 
modal window, by way of which user interface module 
42 provides user control of DSLAM 10 by way of a 
graphical user interface. In addition to general DSLAM 



controls, sub-window 50f permits the user to select 
channel types, signaling protocol, transmission bit rate, 
and quality of service, during the initiation of a channel. 
[0062] Referring now to the case of EMS service ap- 
s plication 40e, by way of which host computer 17 carries 
out the EMS functionality, and with reference to Figures 
5 and 6, EMS service application 40e includes serial 
communications module 44e, which is responsible for 
sending and receiving data to and from the serial port 
to of host computer 17 using serial port driver 46e. As 
shown in Figure 6, serial communications module 44e 
includes message send thread 49 and message receive 
thread 47. 

[0063] On the transmit side of serial communications 
module 44e, message send thread 49 collects and for- 
mats control commands from user interface module 42, 
which are communicated by way of various application 
program interfaces (APIs) as shown in Figure 6. API In- 
stallHandle sets a window "handle" for receiving mes- 
sages in the operating system message queue, effec- 
tively associating certain labeled messages with a par- 
ticular window procedure, which in this example is main 
window 48 (and its appropriate sub-windows 50) of user 
interface module 42. API OpenConnection causes com- 
munications module 44e to open the associated serial 
port of host computer 1 7, specifying the baud rate of the 
communications and the window handle associated 
with user interface module 42 for these messages, as 
installed via API InstallHandle noted above. Message 
receive thread 47 is then launched as a secondary 
thread, to monitor the serial port for incoming message 
data. API CloseConnection is the converse operation of 
API OpenConnection, closing the serial port in this ex- 
ample. For the sending of data from EMS service appli- 
cation 40e to DSLAM 10, as occurs by the user selecting 
a control command via control command sub-window 
50f or script command sub-window 50e, user interface 
module 42 sends API SendHostCommand to serial 
communications module 44e, in which message send 
thread 49 creates a message packet (the body of which 
will contain the control command from user interface 
module 42) that is sent to DSLAM 10, using serial port 
driver 46 e. 

[0064] Data is received by serial communications 
module 44e from DSLAM 10 via serial port driver 46e. 
Message receive thread 47 assembles the incoming da- 
ta packets into a message format. Upon receipt of a 
complete packet, message receive thread 47 posts a 
channel message to operating system message queue 
45 with the appropriate window handle (in this case, the 
handle for user interface module 42) attached thereto. 
User interface module 42 will respond to the posting of 
this message from DSLAM 10 by routing the message 
data to the appropriate sub-window 50; for example, log- 
ging messages are forwarded to sub-window 50a, 
alarms and events are forwarded to sub-window 50b, 
and status information is forwarded to status window 
50d. Channel performance and channel status informa- 



20 



25 



30 



35 



40 



45 



SO 



8 



WEST 



15 



EP 1 079 658 A2 



16 



tion communicated from DSLAM 10 is preferably man- 
aged by a database function within EMS service appli- 
cation 40e, with the results forwarded to channel capac- 
ity sub -window 50c and status window 50d, as appro- 
priate. 

[0065] Referring back to Figure 5, the software archi- 
tecture of DSLAM 10 includes serial port driver 52e, 
which controls the operation of either or both of serial 
ports 27, 28 (Figure 2) in the conventional manner. Host 
port manager 38b is a higher layer software component 
that manages the operation ol the appropriate one (or 
both) of serial ports 27, 28, such management including 
opening and closing the port, associating message han- 
dles with the port, setting and clearing events associat- 
ed with the port, and effecting reads and writes to the 
port. I nth is preferred embodiment of the invention, host 
port manager 38b also transfers those messages asso- 
ciated with EMS functions between EMS service appli- 
cation 40e of host computer 17 and EMS agent 60 in 
DSLAM 10. 

[0066] As shown in Figure 5, the software architecture 
of EMS agent 60 in DSLAM 10 includes message pars- 
ing function 64 and message sending function 66, both 
of which are in communication with host port manager 
38b using APIs associated with the EMS functions. Mes- 
sage parsing function 64 receives command and re- 
quest messages from EMS service application 40e that 
are directed to the monitoring and operation of DSLAM 
10, and parses the messages as appropriate for for- 
warding to DSL channel manager 38c in DSLAM 10. 
Message sending function 66 receives the responsive 
status or informational replies from DSL channel man- 
ager 38c, and arranges messages to be forwarded back 
to EMS service application 40e. 
[0067] In operation, a control or request message in- 
itiated by EMS service application 40e in host computer 
17 will be received by host port manager 38b, following 
its serial port transmission. Host port manager 38b will 
forward the message to message parsing function 64 of 
EMS agent 60 via an API layer. Message parsing func- 
tion 64 will determine whether the message is a control 
command message, intended to. command DSL chan- 
nel manager 38c (or some other application 38 in 
DSLAM 10 such as network manager 38a or host port 
manager 38b itself) to effect certain operations, or a re- 
quest message, intended to request certain status or 
performance information from DSL channel manager 
38c {or another application 38). The message type is 
preferably indicated by way of a message ID field in the 
communicated message from host port manager 38b; 
the message also preferably includes flags that indicate 
whether reply or acknowledgement of the message is 
requested by EMS service application 40e, the se- 
quence of the message in the overall EMS operation, 
and an identifier of the particular DSL channel to which 
the message pertains. The specific protocol of the mes- 
saging may be specified according to the particular ar- 
rangement and architecture of DSLAM 10, and as such 



is contemplated to be within the purview of those skilled 
in the art having reference to this specification. 
[0068] Message parsing function 64 then issues a 
control or request to the indicated application 38, which 

s in turn effects the desired operation and returns a re- 
quested reply or notification to message sending func- 
tion 66 in EMS agent 60. For example, a control com- 
mand or request related to one or more of the DSL chan- 
nels communicating via DSLAM 10 will be forwarded by 

to message parsing function 64 to DSL channel manager 
38c for execution. DSL channel manager 38c will then 
generate a reply message (for example, in response to 
a logging request or other request for information re- 
garding DSL performance) or an acknowledgement 

75 message (for example, in response to a control com- 
mand to indicate execution of the command), and issue 
a message to message sending function 66. Message 
sending function 66 will then pack the responsive mes- 
sage into the format that is specified by the particular 

20 messaging protocol being used for EMS serial port com- 
munications, and issue the message, via an API, to host 
port manager 38b. Host port manager 38b will then gen- 
erate a message via serial port driver 52e to be trans- 
mitted over the serial interface to host computer 1 7. Se- 

25 rial communications module 44e of EMS service appli- 
cation 40e will then receive the message, and forward 
it to user interface module 42 for action and display as 
appropriate. 

[0069] In this manner, host computer 1 7 can carry out 

30 EMS functions for DSLAM 10 in a wide-ranging and in- 
teractive manner. As noted above, these EMS functions 
include such operations as logging of DSLAM and DSL 
channel performance, monitoring DSL bandwidth avail- 
ability, controlling the opening and closing of DSL chan- 

35 nels at particular data rates, notification of events and 
alarm conditions at the DSLAM, and the like. 
[0070] As shown in Figure 5, the preferred embodi- 
ment of the present invention further includes the ability 
of user computers U, remotely coupled to DSLAM 1 0 by 

40 way of LAN 1 4, to also effect EMS monitoring operations 
over DSLAM 10. In this regard, user computer U of Fig- 
ure 5 includes SNMP-EMS service application 40n, and 
DSLAM 10 includes SNMP agent 62 for cooperatively 
operating in combination with SNMP-EMS service ap- 

46 plication 40n, as will now be described in detail. 

[0071] As is well known in the art, SNMP is a conven- 
tional protocol used for the communication of system 
management information between management sys- 
tems and agents. Conventional SNMP requests include 

so "Get" and "GetNext" for retrieving information, and "Set" 
for effecting a control operation. Software agents oper- 
ating under SNMP are also able to notify a registered 
management system upon the occurrence of system 
events. 

55 [0072] As shown in Figure 6, and as typical for SNMP 
networks SNMP agent 62 in DSLAM 10 includes man- 
agement information base (MIB) 70 by way of which 
SNMP managed objects are described. According to 
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SNMP, a management system can manipulate objects 
stored in the MIB via the SNMP agent; in this example, 
applications such as DSL channel manager 38c and us- 
er interface module 42 of SNMP-EMS service applica- 
tion 40n can manipulate objects in MIB 70 using SNMP s 
requests. Each managed object in the system is de- 
scribed in MIB 70 in association with a unique identifier 
and descriptive data concerning the object storage type, 
access type, size, and range. As is known in the field of 
SNMP, MIB 70 may be either of scalar type as a leaf to 
node, or alternatively of a table type having instances of 
the objects. 

[0073] Specifically, forthecaseof DSLAM 10, MIB70 
corresponds to an ADSL-Line Ml B proposed by The AD- 
SL Forum, for example as described in K. McCloghrie, is 
"Management Information Base for Network Manage- 
ment of TCP/IP-based internets: MIB-II 0 , RFC 1213 
(Network Working Group), incorporated herein by this 
reference. The data types managed by MIB 70 in this 
preferred embodiment of the invention include line-spe- 20 
cific data such as line coding type, line status, physical 
description, channel statistics, channel and system per- 
formance, interval information, and various alarms and 
traps regarding loss of frame, loss of signal, loss of pow- 
er, rate changes, and initialization failure. These objects 25 
(including the data and statistics referenced by such ob- 
jects) are not themselves expressly stored within MIB 
70, but rather MIB 70 is arranged by way of indices that, 
when called within SNMP agent 62, initiate a routine to 
acquire the corresponding objects. MIB 70 preferably is 30 
arranged to specify detailed data interface attributes be- 
tween ATUCs and ATURs, as known in the art. 
[0074] As shown in Figure 5, SNMP-EMS service ap- 
plication 40n in user computer U communicates with 
DSLAM 10 by way of a network device driver 46n, and 35 
such network elements (LANs 1 4, 1 4', router 29) as may 
be present in the overall system network. According to 
the preferred embodiment of the invention, SNMP-EMS 
service application 40n preferably contains sufficient in- 
formation regarding the contents of MIB 70 so as to be 40 
able to request the desired information (by way of exe- 
cution of a routine, as noted above) by index. Addition- 
ally, SNMP-EMS service application 40n must register 
itself with SNMP agent 60 upon activation so that, upon 
the occurrence o1 an event in DSLAM 10, SNMP agent 
60 may send an alarm or alert thereto. 
[0075] Figure 7 illustrates the software architecture of 
modules within SNMP-EMS service application 40n. As 
noted above, SNMP-EMS service application 40n in- 
cludes user interface module 42, which is contemplated so 
to be substantially identical to user interface module 42 
in EMS service described hereinabove; of course, some 
differences in the types of monitoring and control func- 
tions implemented on user computers U relative to host 
computer 1 7 may be modified according to the specific ss 
system management to be provided. 
[0076] SNMP-EMS service application 40n also in- 
cludes SNMP manager 44n, which operates in connec- 



tion with user interface module 42, in much the same 
fashion as serial communications module 44e de- 
scribed hereinabove relative to Figure 6. In this regard, 
SNMP manager 44n handles SNMP manager functions 
in a primary "thread" by providing APIs by way of which 
user interface module 42 may send requests to SNMP 
agent 62 in DSLAM 10 over the network. These APIs 
include, as shown in Figure 7, the InstallHandle API by 
way of which a window "handle" is set for receiving mes- 
sages from operating system message queue 45. Anal- 
ogously to serial communications module 44e de- 
scribed above, other APIs include API OpenSNMPSes- 
sion that opens network communication over an open 
SNMP session, and API CloseSNMPSession that clos- 
es the network session. Requests are transmitted by 
SNMP-EMS service application 40n to DSLAM 10 by 
user interface module 42 issuing API SendSNMPRe- 
quest to SNMP manager 44n; in response to Send- 
SNMPRequest, SNMP manager 44n creates a network 
message packet that is sent to DSLAM 10 through the 
operation of network device driver 46n over the network. 
[0077] Additionally, SNMP manager 44n also launch- 
es a secondary thread that will monitor messages re- 
ceived by network device driver 46n from the network, 
and identify messages indicative of events and alarms 
that have been sent by SNMP agent 62 to SNMP-EMS 
service application 40n (once it is registered with SNMP 
agent 62). This secondary thread of SNMP manager 
44n will also forward, to user interface module 42, any 
reply and acknowledgement messages generated by 
SNMP agent 62 in response to requests initiated by user 
interface module 42. When a complete packet of data 
is received from the network via driver 46n, SNMP man- 
ager 44n posts a message to operating system mes- 
sage queue 45 with the window handle for user interface 
module 42, responsive to which user interface module 
42 routes the message data to its appropriate sub-win- 
dow 50 for the message, as described above. 
[0078] While SNMP-EMS service application 40n is 
shown as separately implemented from EMS service 
application 40e, it is contemplated that both SNMP-EMS 
service application 40n and EMS service application 
40e may be implemented on the same computer, for ex- 
ample by way of a single instance of user interface mod- 
ule 42 in combination with both of serial communications 
module 44e and SNMP manager 44n, operating in con- 
junction with operating system message queue 45. 
[0079] Referring back to Figure 5, the software archi- 
tecture of DSLAM 10 includes network device driver 
52n, which effects communication between LAN 14 and 
network manager application 38a. As discussed above 
relative to Figure 4, network manager 38a operates in 
conjunction with data protocol stack 36d to bidirection- 
al^ process network messages within DSLAM control- 
ler 25. In this example, these network messages are 
communicated to SNMP agent 62 by way of SNMP APIs 
that can initialize SNMP agent 62, register SNMP man- 
ager 44n with SNMP agent 62, instantiate an entry into 
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and remove an entry from Ml B 70, query M IB 70 with a 
request, and notify SNMP agent 62 of an event or alarm. 
[0080] As illustrated in Figure 5, the software archi- 
tecture of SNMP agent 62 includes MIB 70, in combina- 
tion with SNMP protocol machine 68 and method rou- s 
tines 72. In its general operation, SNMP protocol ma- 
chine 68 receives a request from SNMP manager 44n 
over the network (i.e., LAN 14, etc.) that includes an in- 
dex into MIB 70. SNMP protocol machine 68 initiates 
one of method routines 72 based upon the received in- io 
dex, and notifies SNMP manager 44n upon completion 
ol the request. Additionally, assuming that SNMP man- 
ager 44n is registered with SNMP agent 62, SNMP pro- 
tocol machine 68 will issue alerts and alarms thereto up- 
on their issuance by DSL channel manager 38c. Details *s 
regarding the components of SNMP agent 62 will now 
be described. 

[0081] Protocol machine 68 encodes SNMP messag- 
es to be sent to the network and decodes SNMP mes- 
sages received from the network. According to the pre- 20 
ferred embodiment of the invention, the SNMP protocol 
corresponds to the ASN.1 description language, with 
coding effected by way of the Basic Encoding Rules 
(BER) format. As is known in the art, BE R encodes each 
value to a tag field that describes the information type, 25 
a length field indicative of the length of information, and 
the value field (i.e., the information itself. Further de- 
scription of the SNMP protocol is provided in Perkins 
and McGinnis, Understanding SNMP MIBs (Prentice 
Hall, 1 997), incorporated herein by reference. In the ar- 30 
chitecture of SNMP agent 62 shown in Figure 5, and as 
is known in the art, SNMP operates as an application 
on top of User Datagram Protocol (UDP) in the Internet 
protocol suite. As such, in the receipt of SNMP messag- 
es over the network, SNMP protocol machine 68 re- 36 
ceives SNMP data packets from the UDP layer (i.e., the 
APIs), and decodes the SNMP packets under BER to 
extract information regarding the source of the SNMP 
message, the SNMP agent address, request types, er- 
ror status and index, variable bindings that describe the 40 
object identifier and values. 

[0082] MIB 70 describes the entities that are being 
managed by DSLAM 10, in the form of a data structure 
having information for each entity registered with SNMP 
agent 62. Typically, information regarding the manage- 46 
ment of DSLAM 10 is maintained as an abstraction in 
MIB 70 and is generated only upon request by SNMP 
manager 44n, rather than being continually maintained 
during DSLAM 10 operation. 

[0083] Management information that is used to modify so 
the operating state of DSLAM 10, such as rate changes 
and the like, is stored in MIB 70 and presented as argu- 
ments to the corresponding one of method routines 72. 
According to the preferred embodiment of the present 
invention, MIB 70 is based upon the proposed ADSL- ss 
Line MIB structure noted above, preferably by way of a 
tree structure. In addition to the ADSL information, ac- 
cording to the preferred embodiment of the invention, 



MIB 70 further includes specific management informa- 
tion such as channel statistics, channel performance, 
channel status, and DSLAM alarms and events, repre- 
sented as object identifiers within MIB 70. According to 
the preferred embodiment of the invention, each DSL 
channel connection handled by DSLAM 10 is described 
as a row in a table or an instance in the tree structure, 
instantiated along with the corresponding DSL channel. 
Also according to the preferred embodiment of the in- 
vention, MIB 70 includes a search method by way of 
which an SNMP query packet can search MIB 70 to find 
the appropriate requested entry. 
[0084] Method routines 72 correspond to software in- 
struction sequences, executable by DSLAM controller 
25 within the overall functionality of SNMP agent 62, to 
respond to queries and requests issued by SNMP man- 
ager 44n. According to the preferred embodiment of the 
invention, method routines 72 operate according to a 
dispatch table that maps the identity of management in- 
formation requested by SNMP manager 44n (or by 
SNMP agent 62 itself in response to an event) to the 
desired routine; this management information identity 
preferably includes both the management information 
itself plus an individual instance in MIB 70 to which it 
refers. 

[0085] In operation, SNMP agent 62 receives SNMP 
messages over the network from SNMP manager 44n, 
initiated by the user via user interface module 42 of user 
computer U. These messages are processed by net- 
work manager 38 using data protocol stack 36d, and for- 
warded as SNMP data packets to SNMP protocol ma- 
chine 68. SNMP protocol machine 68 decodes these 
SNMP packets to extract the source of the SNMP mes- 
sage, the SNMP agent address, request types, error 
status and index, variable bindings that describe the ob- 
ject identifier and values. The dispatch table maps the 
object identities to method routines 72 for execution. Up- 
on execution of the method or upon the occurrence of 
an event or alarm in DSLAM 10, SNMP protocol ma- 
chine 68 issues the corresponding SNMP messages 
back over the network to the registered SNMP manager 
44n, by encoding the event or response under BER and 
formatting the encoded message as SNMP data pack- 
ets. 

[0086] For example, SNMP manager 44n may issue 
a request to DSLAM 1 0 for the performance statistics of 
a specific DSL channel, as selected by the user via user 
interface module 42. The request is driven onto the net- 
work by network device driver 46n of user computer U, 
and is received in the appropriate manner by DSLAM 
10 under the operation of network device driver 52n. 
Network manager 38a forwards the message to SNMP 
agent 62, within which SNMP protocol machine 68 de- 
codes the SNMP message to determine that the mes- 
sage is a request for DSL channel statistics, along with 
the identity of the particular DSL channel to be interro- 
gated. This request is forwarded to method routines 72 
which maps the request and the object identities to the 
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appropriate method; information contained within the 
corresponding instance in MIB 70 is then obtained as 
appropriate, and the method is executed by SNMP 
agent 62 by issuing a request to DSL channel manager 
38a for the appropriate DSL channel statistics. Because s 
of the operation of MIB 70, each managed entity has its 
own method within method routines 72. DSL channel 
manager 38a will then issue the appropriate reply to 
SNMP agent 62, which updates its MIB 70 accordingly 
and initiates SNMP protocol machine 68 to encode an JO 
SNMP message back to requesting SNMP manager 
44n. Upon receipt of the reply, user interface module 42 
in SNMP-EMS service application 40n will then display 
the channel statistics to the user as appropriate. 
[0087] It is of course to be understood that, while a is 
single user computer U is illustrated in Figure 5, multiple 
user computers U having SNMP-EMS service applica- 
tion 40n installed thereupon will likely be coupled to 
DSLAM 10 by way of various network facilities such as 
LAN 1 4. As such, multiple SNMP managers 44n will like- 20 
ly be registered with SNMP agent 62 of DSLAM 10, so 
that monitoring and control requests may be issued by 
multiple users on the network, and with events and 
alarms forwarded to such users, depending on the level 
of management desired. 25 
[0088] In combination with the overall EMS function 
provided according to the present teaching, therefore, 
the preferred embodiment of the invention permits users 
to monitor and manage the DSLAM system both locally 
by way of the EMS functionality of a host computer, or 30 
remotely by way of a network connection. As a result, 
great flexibility and functionality in the management, 
control, and monitoring of the DSLAM is provided by em- 
bodiments of the present invention. Furthermore, it is 
contemplated that the EMS of an embodiment of the 35 
present invention also facilitates debugging of a DSLAM 
installation, particularly by way of the host computer. 
Other functionality is also now enabled through the in- 
telligent EMS of the present teaching, including the abil- 
ity to download and install upgraded client modem soft- *o 
ware from the EMS systems via the DSLAM. 
[0089] While aspects of the present invention have 
been described according to preferred embodiments, it 
is of course contemplated that modifications of, and al- 
ternatives to, these embodiments, such modifications 46 
and alternatives obtaining the advantages and benefits 
of aspects of this invention, will be apparent to those of 
ordinary skill in the art having reference to this specifi- 
cation and its drawings. It is contemplated that such 
modifications and alternatives are within the scope of so 
this invention as subsequently claimed herein. 
[0090] Insofar as embodiments of the invention de- 
scribed above are implementable, at least in part, using 
a software -control led programmable processing device 
such as a Digital Signal Processor, microprocessor, oth- S5 
er processing devices, data processing apparatus or 
computer system, it will be appreciated that a computer 
program for configuring a programmable device, appa- 



ratus or system to implement the foregoing described 
methods is envisaged as an aspect of the present in- 
vention. The computer program may be embodied as 
source code and undergo compilation for implementa- 
tion on a processing device, apparatus or system, or 
may be embodied as object code. The skilled person 
would readily understand that the term computer in its 
most general sense encompasses programmable de- 
vices such as referred to above, and data processing 
apparatus and computer systems. 
[0091] Suitably, the computer program is stored on a 
carrier medium in machine or device readable form, for 
example in solid-state memory or magnetic memory 
such as disc or tape and the processing device utilises 
the program or a part thereof to configure it for operation. 
The computer program may be supplied from a remote 
source embodied in a communications medium such as 
an electronic signal, radio frequency carrier wave or op- 
tical carrier wave. Such carrier media are also envis- 
aged as aspects of the present invention. 
[0092] The scope of the present disclosure includes 
any novel feature or combination of features disclosed 
therein either explicitly or implicitly or any generalisation 
thereof irrespective of whether or not it relates to the 
claimed invention or mitigates any or all of the problems 
addressed by the present invention. The applicant here- 
by gives notice that new claims may be formulated to 
such features during the prosecution of this application 
or of any such further application derived therefrom. In 
particular, with reference to the appended claims, fea- 
tures from dependent claims may be combined with 
those of the independent claims and features from re- 
spective independent claims may be combined in any 
appropriate manner and not merely in the specific com- 
binations enumerated in the claims. 



Claims 

1. A data communications system including an access 
multiplexer for processing data communications, in- 
cluding a network interface and including a host 
processor coupled to the network interface, charac- 
terized in that: 

the access multiplexer, comprises 

a plurality of interface circuits, each for cou- 
pling the access multiplexer to a communi- 
cations facility for the bidirectional commu- 
nication of data with a client location, 
signal processing circuitry, for performing 
digital operations upon data corresponding 
to signals received from client locations by 
way of the plurality of interface circuits and 
corresponding to signals to be transmitted 
to client locations by way of the plurality of 
interface circuits, 
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a network interface, 
a local communications interface, and 
a controller, coupled to the signal process- 
ing circuitry, to the network interface, and 
to the local communications interface, for £ 
controlling the communications between 
the signal processing circuitry and the net- 
work interface and for managing commu- 
nications channels established at the plu- 
rality of interface circuits according to an el- 10 
ement management system agent respon- 
sive to control command and information 
request messages received from the local 
communications interface, and for gener- 
ating reply messages to the local commu- ^ 
nications interface responsive to said con- 
trol command and information requests; 
and 

the host computer is coupled to the local com- 20 
munications interface and is programmed to 
execute an element management system serv- 
ice application to receive user inputs corre- 
sponding to management functions of the ac- 
cess multiplexer system, to generate control 25 
command and information request messages 
in response to such user inputs and output said 
control command and information request mes- 
sages at the local communications interface, 
and to generate display information cor re- 30 
sponding to reply messages received at the lo- 
cal communications interface. 



command and information request messages re- 
ceived from the network interface, and for generat- 
ing reply messages to the network interface respon- 
sive to said control command and information re- 
quests. 

5. The multiplexer system of claim 4, wherein the con- 
troller comprises a programmable device operable 
according to a plurality of software elements com- 
prising: 

a communications channel manager, for initial- 
izing and dropping communications channels, 
and for defining communications parameters 
for the communications channels; 
a host port manager for controlling communi- 
cations over the local communications inter- 
face; and 

a network manager for controlling communica- 
tions over the network interface; 

wherein the controller operates according to 
the element management system agent to cause 
the communications channel manager to execute 
operations responsive to control commands and re- 
quests received at the local communications inter- 
face by the host port manager, and operates ac- 
cording to the network protocol agent to cause the 
communications channel manager to execute oper- 
ations responsive to control commands and re- 
quests received at the network interface by the net- 
work manager. 



2. The access multiplexer system of claim 1, further 
comprising a local area network coupled to the net- 
work interface of the multiplexer. 

3. The access multiplexer system of claim 1 or 2, fur- 
ther comprising an Internet gateway coupled to the 
local area network. 

4. The access multiplexer system of claim 2, or claim 
3 dependent on claim 2, further comprising: 

a user computer, coupled to the local area net- 
work, and programmed to execute a network proto- 
col element management system service applica- 
tion to receive user inputs corresponding to man- 
agement functions of the access multiplexer sys- 
tem, to generate control command and information 
request messages in response to such user inputs 
and output said control command and information 
request messages to the local area network, and to 
generate display information corresponding to reply 
messages received at the local area network; 

wherein the controller of the multiplexer is al- 
so for managing communications channels estab- 
lished at the plurality of interface circuits according 
to a network protocol agent responsive to control 



6. The multiplexer system of any preceding claim, 
35 wherein the communications between the multi- 
plexer and client locations are digital subscriber line 
communications. 

7. The multiplexer system of any preceding claim, 
40 wherein the controller comprises a digital signal 

processor integrated circuit. 

8. The multiplexer system ol any preceding claim, 
wherein the local communications interface com- 

4* prises a serial interface. 

9. A method of controlling communications at an ac- 
cess multiplexer coupled to a plurality of client lo- 
cations, and coupled to a network, comprising the 

so steps of: 

receiving a command control request at a host 
computer; 

operating the host computer to communicate a 
66 command control request message to the ac- 

cess multiplexer over a local communications 
interface; 

responsive to receiving the command control 
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request message, parsing the command con- 
trol request message within an element man- 
agement system software agent, 
operating the element management system 
software agent to cause a communications s 
channel managerto execute the corresponding 
command control request and generate a reply; 
receiving the reply at the element management 
software agent; and 

generating a reply message to the host compu- io 
ter over the local communications interface. 

10. The method of claim 9, further comprising: 

receiving a command control request at a user « 
computer; 

operating the user computer to communicate a 
command control request message to the ac- 
cess multiplexer over a local area network; 
responsive to receiving the command control 20 
request message, decoding the command con- 
trol request message within an network proto- 
col software agent; 

calling a method routine in the network protocol 
software agent corresponding to the command 25 
control request message; 
causing the communications channel manager 
to execute the method routine called in the call- 
ing step; 

encoding a reply at the network protocol soft- 30 
ware agent, corresponding to a result of the ex- 
ecuted method routine; and 
generating a reply message to the user compu- 
ter over the local area network. 

35 

1 1 . The method of claim 1 0, wherein the command con- 
trol request corresponds to the establishing of a 
communications channel at the multiplexer. 

12. The method of 10 or 11, wherein the command con- 40 
trol request corresponds to the setting of a state of 

a communications channel at the multiplexer. 

13. The method of any one of claims 10 to 12, wherein 
the command control request corresponds to a re- *s 
quest for performance information regarding a se- 
lected communications channel at the multiplexer. 

14. The method of any one of claims 10 to 13, wherein 
the command control request corresponds to a so 
downloading of communications software to a de- 
vice at a client location. 

15. The method of any one of claims 10 to 14, further 
comprising: ss 

responsive to the multiplexer operating at an 
alarm condition, operating the communications 



channel manager to issue an alarm to the ele- 
ment management system software agent; and 
responsive to receiving the alarm, operating the 
element management system software agent 
to generate an alarm message to the host com- 
puter over the local communications interface. 

16. The method of any one of claims 10 to 15, further 
comprising: 

responsive to the multiplexer operating at an 
alarm condition, operating the communications 
channel manager to issue an alarm to the net- 
work protocol software agent; and 
responsive to receiving the alarm, operating the 
software agent to generate an alarm message 
to the user computer over the local area net- 
work. 

17. A computer program comprising machine or device 
readable instructions for configuring a computer to 
implement the method of any one of claims 9 to 16. 

18. A computer program comprising machine or device 
readable instruction, said instructions translatable 
for configuring a computer to implement the method 
of any one of claims 9 to 16. 
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